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[57] ABSTRACT 

A method for predicting a number of agents required to 
provide a given service level in a force management 
system is described. The force management system has 
the capability to generate call handling performance 
data including average call arrival rate and average 
handling time per call. From this data, the method cal- 
culates an offered load "a" equal to the average arrival 
rate of calls for the system times the average handling 
time per call. Using the calculated offered load, the 
method calculates two predictor values and then uses 
these values in successive Erlang C calculations to lo- 
cate the desired number of agents required to provide a 
given service level. 

3 Claims, 8 Drawing Sheets 
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1 2 

METHOD FOR PREDICTING AGENT BRIEF SUMMARY OF THE INVENTION 

REQUIREMENTS IN A FORCE MANAGEMENT It is an object of the present invention to provide a 

SYSTEM force management system and method for planning, 

5 scheduling and managing personnel in an environment 
TECHNICAL FIELD m which there is a varying workload by time of day and 

day of week to be staffed with a variable number of 
The present invention relates generally to computer- servers. One such environment is a telephone call center 
ized systems and methods for planning, scheduling and m wmch j nc0 ming calls are delivered among a plurality 
managing personnel in an environment in which there is 10 0 f agents for response. While the following description 
a varying workload by time of day and by day of week use s a telephone call center as a representative example 
to be staffed with a variable number of servers. Q f one environment for implementing the teachings of 

RArirrpoTTwn hf thp mvPWTTnw ^ P r «*e nt invention, the invention is not to be con- 

BACKGROUND OF THE INVENTION strued ^ limited to the call center application. Indeed, 

Force management systems for use in planning, 15 the principles of the invention are applicable to any 

scheduling and managing personnel in a telephone call work environment in which there are required to be 

center are known in the prior art. Such systems typi- varying workloads, by time of day and day of week, to 

cally include a basic planning capability to enable a call be staffed with a variable number of servers, 

center supervisor to forecast future call loads and the It is another object of the invention to describe a 

number of servers or "agents" necessary to service that 20 personnel resource management system and method for 

load. Most prior art systems also include a simple sched- managing large numbers of agents with a single system 

uling capability which then functions to allocate agent wherein groups of operators can be geographically-dis- 

work hours according to the staffing requirements that P»»d but still handle the same call type. The mvention 

have been forecast. Agents are then manually or auto- * us F™te C ™ tTol \° W^J ^ 

matically assigned to fill the schedules. These systems 25 ad vantage of the capacities of modern distal switches. 

ii i • i j i- j • • .a ' . More specifically, the present invention advanta- 

usually also mclude other adnumstrative and reportmg geous]y p % %^J o{ functionality mi ^ntto! 

capabilities. between a force management central center, which is 

Prior art force management systems suffer from many ^ for longe A C nn planning and administra- 

disadvantages. Such systems rely on conventional time- 3Q g plurality ^ f local management units responsi- 

series forecasting techniques to generate forecasts for a We for ^ ^ y management. Preferably, at 

large block or unit of time, e.g., a month. These tech- kast Qne management unit or "MU" is located at a 
niques then use fixed factors to decompose the monthly geographical location distinct from other management 
forecast into weekly, daily, and then hourly or smaller units of the system . This architecture provides the flexi- 
increments. This approach is computationally-efficient 35 ^j ty t0 accommodate significant changes in the organi- 
but lends itself to accuracy only on a macro scale, e.g. zation and configuration of call handling units and the 
month-to-month, as opposed to reflecting real changes relationship between them. 

in call volumes as they actually occur in the historical it is another object of the invention to provide a 
data for the call center. Prior art systems thus do not management system for personnel of a call center which 
have the flexibility to be responsive to changing condi- 40 includes tools to develop and adjust short term forecasts 
tions so as to forecast future call loads and provide to quickly reflect special call-handling events and to 
realistic scheduling of personnel to meet the dynamic develop forecasts that capture long-term variations in 
load requirements of a typical telephone call center. call activity. In particular, the invention generates a 
Moreover, the prior art systems are typically struc- forecast of a call load expected to occur during rela- 
tured around a single call center location. Therefore, 45 tively small individual future time periods, e.g., half 
while telecommunications switching advances can ef- hour increments of a work day, as well as the number of 
fectively connect numerous locations together, there is agents required to service the expected call load during 
no prior art management system that can provide effi- each individual period. This technique is the opposite 
cient forecasting and requirements generation at a cen- from P rior art tmie-senes forecasting wherein forecasts 
tral location with schedule generation and schedule 50 are generated in a top down approach starting with a 
management at individual dispersed locations. Yet an- lar « e f ? re <f P™*-/*- * mont * or f a we * *f 
othe^ SeTts^ 

is the inabUity ^of such systems to efficiently generate of ^present mvcntion ^ ad^g^ly 

optimal workshifts ( tours ) for agents once forecasting $$ changcs m call activity which m ^ a Tesult 

is complete. Further these systems do not have the of the fact that the re , ative ition of a riod m a 
capability to efficiently generate schedules to satisfy month ^ volumes . The invention therefore 

agent preferences, availability and seniority. provides much more accurate forecasts over prior art 

The deficiencies of prior art force management sys- techniques, 
terns have given rise to a curious result. In a call center ^ It is stm mother object to provide an efficient method 
environment,, telephone call center supervisors are 0 f generating workshifts or "tours" for agents of a 
forced to manage their personnel based on the capabili- workplace that optimizes the utilization of operator 
ties of their force management system, as opposed to the s taff. Another object is to provide automatic scheduling 
capabilities of their switching system and their staffing of the agents to these tours taking full account of agent 
resources. 65 availability, preferences, seniority and fairness. 

It would therefore be desirable to overcome the prob- It is a further object of the invention to provide a 
lems associated with such prior art force management computer-based force management system and method 
systems. for a telephone call center that plans personnel require- 
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ments in line with changing call volumes in a manner 
that service level requirements are met at the lowest 
possible cost. 

It is still another object to provide a force manage- 
ment system which provides an easy-to-use interface to 5 
enable supervisors to view call forecasts and schedules 
from multiple sites in the call center. 

It is a further object to provide a force management 
system having a unique schedule management visual 
display to enable supervisors to adequately monitor and 10 
revise schedules of agents to insure that call handling 
responsibilities are met. 

Yet another object is to provide a force management 
system that includes a unique performance analysis 
visual display which enables supervisors to review de- 15 
tailed real-time data and make quick, informed staffing 
decisions in response thereto. 

In one basic embodiment of the invention, these and 
other objects of the invention are provided in a method 
for managing a team of agents at a telephone call center, 20 
comprising the steps of: 

(a) organizing the team of agents into a plurality of 
management units, each management unit having one or 
more groups of individual agents; 

(b) defining one or more tour templates each describ- 25 
ing a bounded work shift having work rules and operat- 
ing constraints; 

(c) generating a forecast of a call load expected to 
occur during individual future time periods and a num- 
ber of agents required to service the expected call load 30 
during each individual period; 

(d) allocating the expected call load among the plu- 
rality of management units; 

(e) correlating the tour templates with the forecast to 
generate a set of tours for each management unit, each 35 
tour defining a predetermined daily work schedule for a 
theoretical agent of the management unit; 

(0 assigning the individual agents of each manage- 
ment unit to the generated tours for the management 
unit; and 40 

(g) generating a schedule for each individual agent of 
the management unit. 

Alternatively, steps (e), (0 and (g) are implemented 
together to automatically assign the individual agents of 
each management unit to the generated tours for the 45 
management unit according to agent preferences, avail- 
ability, seniority and fairness, and then producing 
schedules for each individual agent. 

The organization of the team of agents into manage- 
ment units provides significant advantages over the 50 
prior art in that it enables scheduling and management 
of large, distributed teams of call center agents. Man- 
agement units are generally located at different physical 
locations. Therefore, a number of small call center of- 
fices can be interconnected and function as one large, 55 
efficient call-handling team. Each management unit, 
however, is managed locally and thus can have its indi- 
vidual work rules and hours of operation. Such individ- 
ual management of the units facilitates local control of 
staffing and the ability to handle work rules that may 60 
vary from office to office. 

The invention also facilitates the efficient manage- 
ment of the individual agents of the management unit 
based on real-time performance statistics and meaning- 
ful display of the generated agent schedules. In particu- 65 
lar, unique visual displays of agent schedules and man- 
agement unit performance are provided to enable local 
supervisors to make fast, informed staffing decisions for 



their management unit. The schedule management dis- 
play is advantageously built around the display of a 
"time line" for each agent of the management unit, with 
each unit in the time line preferably corresponding to a 
predetermined period of time, e.g., a fifteen minute 
interval. The time line for each agent further includes 
one or more user-defined schedule activity codes 
therein, e.g., "B" for break, "L" for lunch, "m" for 
meeting, etc., for representing the agent s planned status 
for the day and the nature of any activities that might 
prevent the agent from attending to incoming calls. 
Preferably, different activities are displayed in contrast- 
ing colors according to activity class denoting potential 
availability. The system further enables the supervisor 
to dynamically edit the agent schedules and display lists 
of agents and their schedules sorted by predetermined 
criteria such as agent names, members of a carpool, 
schedule start times, schedule end times, agents having 
lunch breaks at 11:30, etc. 

The schedule management display thus provides a 
unique time line (as opposed to a textual) representation 
of agents within a management unit to enable the super- 
visor to visualize occupancy and potential staffing prob- 
lems. The schedule management display cooperates 
with the related performance analysis screen which 
enables the in-charge supervisor to obtain a meaningful 
view of what call activity has actually occurred, a best 
guess estimate of what call activity will occur, and a 
means of making staffing decisions based on such infor- 
mation. By switching back and forth between the 
schedule management and performance analysis 
screens, the in-charge supervisor can make informed 
staffing decisions. 

Staffing changes at, the management unit are transmit- 
ted back to the centralized computer of the force man- 
agement system and then regularly broadcast back to 
the other management units of the system. The perfor- 
mance analysis screen at the management unit is thus 
continuously updated (in real-time as data is received) 
with modified team call handling performance data. 

The present invention also includes an intra-day 
reforecasting capability which operates automatically 
as new data is received (data is usually received every 
fifteen minutes and posted every half-hour). Intra-day 
forecasting continually looks at the performance of the 
system and the original forecast data up to the time of 
the day for which data has been received. The system 
reforecasts the conditions expected for the rest of the 
day using a reality weighting factor, which takes into 
consideration the amount of data received (i.e., how 
early in the day the intra-day reforecast is being com- 
puted). 

The system also includes a "what-if * reforecasting 
capability to permit the call center supervisor (in the 
case of the overall team) or the local in-charge supervi- 
sor (in the case of the management unit) to determine 
the effects on team service level if the number of avail- 
able agents is altered in a particular management unit. 

The foregoing has outlined some of the more perti- 
nent objects of the present invention. These objects 
should be construed to be merely illustrative of some of 
the more prominent features and applications of the 
invention. Many other beneficial results can be attained 
by applying the disclosed invention in a different man- 
ner of modifying the invention as will be described. 
Accordingly, other objects and a fuller understanding 
of the invention may be had by referring to the follow- 
ing Detailed Description of the preferred embodiment. 
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BRIEF DESCRIPTION OF THE DRAWINGS j£* the MIS 14 1 ° t"™™ * "*"*■ . 

For a more complete understanding of the present The centralized computer 12 is linked to a plurality of 

invention and the advantages thereof, reference should workstations 24 organized into a plurality of distinct 

be made to the following Detailed Description taken in 5 groups or so-called management units 22a, 22b, 22/i. 

connection with the accompanying drawings in which: With reference simultaneously to FIGS. 1-2, a "team" 

FIG. 1 is a block diagram of the basic architecture of of call center agents is organized according to the in- 

the force management system of the present invention; vention into the plurality of "management units,*' each 

FIG. 2 is a schematic representation of how a team of management unit ("MU") having a predetermined num- 

agents is organized into groups of management units 10 ber of agent groups. An MU is thus a set of agent groups 

according to the invention; that is managed locally as a single unit. In this manner, 

FIG. 3 is a flowchart showing the basic functional each management unit can have its individual work 

steps involved in force management according to the rules and hours of operation. A management unit can be 

invention; and is often geographically-separate from other man- 

FIG. 4 is a schematic data flow diagram of the func- IS agement units. Although not shown in detail, a single 

tional architecture of the central computer of the force telephone switch may likewise be associated with more 

management system of the present invention; than one team, and more than one MU can be associated 

FIG. 5 is a representative tour template according to with more than one team. One team can therefore han- 

the invention; die one call type while another team handles a second 

FIG. 6 is a flowchart describing the portion of the 20 call type. Thus the system is designed to accommodate 

generate forecast routine of FIG. 4 used to generate a not only geographical dispersal of management units, 

Call Volume forecast; but also multiple call types dispersed among multiple 

FIG. 7 is a flowchart describing the inverse Erlang C management units and multiple geographical locations, 

calculation portion of the generate forecast routine of Referring now back to FIG. 1, each management unit 

FIG. 4; 25 has one or more supervisor workstations 24 associated 

FIG. 8 is a representation of the Schedule Manage- with each group of agents therein. Each of the worksta- 

ment screen of the present invention; and tions 24 includes a video display terminal, a keyboard 

FIG. 9 is a representation of the performance Analy- for enabling entry of appropriate administrative com- 

sis screen in a forecast mode of operation; and mands to manage personnel resources, and a suitable 

FIG. 10 is a data flow and functional architecture of 30 control circuit for controlling communications between 

one of the MU workstations showing the details of how the terminal and the central computer via one of the 

the Schedule Management and performance Analysis lines 26a-26n. As will be described, the supervisory 

screens are built; and workstation 24 provides displays of status. The central 

FIG. 11 is a detailed flowchart describing the computer is preferably an AT&T 3B2/1O0O Model 80. 

tour/schedule generation algorithm of the present in- 35 Each supervisor workstation can be implemented using 

vention. a personal computer system having a suitable 80286 or 

Similar reference characters refer to similar parts or 80386 processor, memory storage disks, input/output 

steps throughout the several views of the drawings. devices and communications interface equipment. 

nFTAiT pn nFSrHTPTinN Referring now to FIG. 3, one method for planning, 

DfciAILfcD DfcbCKIKIiUN ^ schedu i ing ^ managing a team of agents at a tele- 

As described above, the force management system of phone call center according to the invention is de- 

the present invention is adapted for planning, schedul- scribed. The method begins at step 25 by organizing the 

ing and managing personnel in an environment in which team of agents into a plurality of management units, 

there is a varying workload by time of day and by day each management unit having one or more groups of 

of week to be staffed with a variable number of servers. 45 individual agents. As noted above, the organization of 

In general, the servers will be required to respond to an the team of agents into management units provides 

event load which has been forecast to occur in the fu- significant advantages in that it enables scheduling and 

ture. One such environment is a telephone call center in management of large, distributed teams of call center 

which, for example, an "event" is an incoming call to agents. Management units are generally located at dif- 

the center. For the remainder of the description, the 50 ferent physical locations. Therefore, a number of small 

telephone call center environment is described only for call center offices can be interconnected and function as 

exemplary purposes and not by way of limitation. As one large, efficient call-handling team. Each manage- 

seen in FIG. 1, the force management system includes a ment unit, however, is managed locally and thus can 

personnel resource management central computer 12. have its individual work rules and hours of operation. 

This computer is connected to a management informa- 55 At step 27, one or more tour templates are defined, each 

tion system ("MIS") 14, which forms part of a tele- template describing a bounded work shift having work 

phone switch and automatic call distributor ("ACD") rules and operating constraints. At step 29, a forecast is 

system known in the prior art, namely, the AT&T generated of a call load expected to occur during indi- 

5ESS® Switch ACD/MIS. It is known in the art that vidual future time periods, e.g., half hour increments, 

an ACD serves to automatically make telephone con- 60 and a number of agents required to service the expected 

nections between agent workstations (not shown) and call load during each such individual period. As will be 

input telephone lines. As shown in FIG. 1, the MIS 14 described, forecasting according to the invention takes 

receives real-time data from the ACD and stores this advantage of the statistical observation that the best 

data in the MIS database 16. Data is delivered to the single predictor of call volumes in any given period is 

force management system database 18 of the central 65 the corresponding period, by time of day and day of 

computer 12, preferably at fifteen (15) minute intervals. week, of previous weeks. Forecasting of call volumes 

As will be described, agent schedules are delivered also relies on other factors such as the relative position 

from the central computer 12 back to the MIS 14 to of various days with a given month. According to the 
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invention, short-term agent requirements are based on tive parameters are used by the generate forecast rou- 

factors such as call load forecast, service level objec- tine 46 to calculate a number of so-called Full Time 

tive, expected agent occupancy and budgeting consid- Equivalent ("FTE") agents for various periods. An 

erations. FTE is a scaleless number which depends on the time 

Following the generation of a forecast, the method 5 scale being examined. Thus, for a half-hour period, an 

continues at step 31 to allocate the expected call load FTE of fifty (50) means that fifty (50) agents are avail- 

among the plurality of management units. This function able for thirty (30) minutes each or that one hundred 

enables the centralized computer 12 of the overall team (100) agents are available for fifteen (15) minutes each, 

to distribute the responsibility for answering calls ac- etc. 

cording to expected available staffing as administra- 10 After generating the staffing requirements for each 

tively determined. Moreover, the allocation is variable interval, the force management system enters a schedul- 

by each half-hour of each day of the week. This opera- ing function. The purpose of the scheduling function is 

tion enables the call center to realize significant facilities to allocate work hours according to the staffing require- 

and management cost savings. For example, if there are ments that have been forecast. Scheduling has three 

four MU's expected to have equivalent amounts of staff- 15 basic components: tour generation, agent assignment 

ing but one MU, e.g., MU1, closes one hour before the and schedule generation. A tour is a given work sched- 

other MU's, the call center supervisor can setup the ule for a set number of working days and includes a start 

allocations for each MU at 25% until the end of the day, time, an end time, break time(s), meal time, workdays 

when the other three MU's are then each allocated and tour length. Tour generation is the process of 

33.3% of the calls. When MU1 closes, no falloff in ser- 20 matching the staffing requirements with the staffing 

vice level then occurs. Of course, in operation, incom- possibilities, as defined by staffing restrictions such as 

ing calls always go to the first available agent, regard- hours of operation, permissible tour templates and maxi- 

less of the location of that agent. mum and minimum number or particular tour tem- 

At step 33, tour templates are correlated with the plates. A tour template defines the boundaries of per- 

forecast to generate a set of "tours" for each manage- 25 missible tours, e.g., the earliest and latest agent start 

ment unit, each tour defining a predetermined daily times, maximum hours per week, number of breaks, etc. 

work schedule for a theoretical agent of the manage- FIG. 5 shows a representative tour template. Accord- 

ment unit. The method continues at step 35 by assigning ing to the invention, tours are generated so that staffing 

the individual agents of each management unit to the requirements and staffing restrictions are optimized for 

generated tours for the management unit. At step 37, a 30 a low level of over- or under-staffing, 

schedule is generated for each individual agent of the Referring now back to FIG. 4, in one embodiment of 

management unit. Thereafter, once a work shift begins the invention a. generate tours routine 52 is used to 

at step 39, the shift supervisor for the management unit create tours for "theoretical" agents of each manage- 

manages the agents through the use of a novel user ment unit based on the tour templates and the forecast 

interface as will be described in more detail below. 35 FTE requirements for a particular period. Tours, which 

Referring now to FIG. 4, a schematic data flow dia- are stored in Tours database 53, at this point do not have 

gram is shown of the functional architecture of the particular agents associated with them. Thereafter, the 

central computer 12 of the force management system. supervisor(s) assign agents to generated tours using a 

As seen in FIG. 4, the MIS 12 provides the force man- list of named agents. Alternatively, agents can be as- 

agement system with statistics concerning incoming 40 signed using an automatic process instead of manually 

calls and the activities of the agents in responding to as will be described below. The daily schedules for 

those calls. The force management system preferably every agent are then prepared by a generate schedules 

processes data based in thirty (30) minute intervals. routine 54 and stored in Schedules database 56. Time 

Raw statistical data is available from the MIS every 15 utilization reports 57 can be generated from the Sched- 

minutes, therefore, the system includes a Results data- 45 ules database 56 if desired. 

base 44 for storing the raw data from the MIS 12. Com- Referring now to FIG. 6, the portion of the generate 

mands entered via a management workstation 24 are forecast routine 46 of FIG. 4 used to forecast Call Vol- 

used to revise the data where appropriate. The revised ume is shown in detail. AHT is forecast in a similar 

data is then used by a generate forecast routine 46 manner. As described generally above, forecasting ac- 

which generates forecasts that are then stored in a Fore- 50 cording to the present invention focuses initially on 

casts database 48. Initially, two basic elements are fore- individual small periods of time, e.g., half-hour incre- 

cast: Call volume and Average Handling Time ments, as opposed to macro or lengthy forecasting peri- 

(" AHT'). Call Volumes and AHT are forecast in pref- ods such as months or weeks. This approach provides 

erably half-hour increments. In the call center applica- significant improvements over the prior art, especially 

tion, AHT represents the average time an agent takes to 55 where comprehensive and consistent historical data 

handle a call. exists for use in generating the forecast. 

In order to generate the staffing requirements, the Forecasting is based on the statistical observation that 

generate forecast routine 46 uses three (3) other parame- the best single predictor of future call volumes in any 

ters, Service Objective, Occupancy and a Budget fac- given period is the corresponding period, by time of day 

tor, provided from an administrative database 50. The 60 and day of week, of previous weeks. The best predictor 

Service Objective is the level of service which is desired of next Monday at 10:30 a.m. is last Monday at 10:30 or 

to be provided to customers. Service Objective is se- rather the series of such recent time periods, i.e., the 

lected by the system operator and is expressed as a most current data available from the MIS. Indeed, if the 

percentage of calls answered within a set time. Occu- forecast is being performed for example on Jan. 15, 

pancy is the measure of the percentage of time in which 65 1991, then the very best data for use in generating the 

agents are handling calls. The Budget factor represents forecast according to the invention is some period of 

an allowance for unscheduled unavailability such as time (e.g., 13 weeks) leading up to and ending Jan. 14, 

absences or vacations. The forecast data and administra- 1991. As wUl be seen, this is the technique implemented 
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by the present invention. Moreover, the technique also 
recognizes and uses calendar variability factors, i.e., the 
fact that the relative position of a period in a month 
affects call volumes, to further weight the forecast. For 
example, often the first Monday in a month has a char- 5 
mcteristically different volume from the third Monday. 
According to the invention, forecasting is carried out 
by determining the relative weight of these factors in 
the most current historical data, as determined by a 
statistical analysis. 10 

More specifically, and with reference to FIG. 6, there 
is shown a flowchart of a novel method for generating 
a forecast of Call Volumes expected to occur in a tele- 
phone call center during a future time span. The method 
uses the force management system historical database 15 
which is derived from results received from the MIS. 
THE FMS database includes historical call volume data 
preferably up to the very last day (i.e., the "previous 
day") before the day in which the forecast is being 
generated. The method begins at step 31 by scanning 20 
the historical data over a predetermined time period 
(eg., two years) to produce a historically-observed 
"growth rate," i.e., a long-term increase or decrease in 
call volumes. The method then continues at step 33 by ^ 
defining a "forecast base period" corresponding to a 
predetermined time period (e.g., 13 weeks) ending with 
the previous day. 

"Thereafter, a first processing loop begins at step 35 
for each individual time increment of a given day of the ^ 
week, beginning with a first individual time increment 
of a week, continuing increment-by-increment and end- 
ing with a last individual time increment of the week. 
Each increment is a half-hour period and thus the loop, 
for example, begins with the 12:00-12:30 a.m. increment 35 
on Sunday morning and continues with each individual 
increment (12:30-1:00 a.m., 1:00-1:30 a.m. . . . ) 
throughout Sunday. Once Sunday is complete, the loop 
continues with Monday, and likewise to the end of the 
week. The loop is complete upon processing of the 
11:30-12:00 midnight increment on Saturday night. Of 
course, depending on the hours of operation of the team 
during the future span, it should be appreciated that 
parts of the looping can be skipped. 

The following steps are then performed within the 45 
first processing loop for each individual time increment. 
At step 37, the call volume data in the forecast base 
period is averaged. Using the first increment described 
above, this step would average the Sunday 12:00 call 
volume data for each of the 13 weeks in the forecast 50 
base period. At step 39, the standard deviation of the 
averaged call volume data is calculated. Any call vol- 
ume data that deviates two standard deviations from the 
mean is then discarded at step 41 to prevent biasing of 
the forecast. At step 43, the call volume data remaining 55 
in the forecast base period is weighted. Weights are 
assigned to the data under one or more predetermined 
criteria such as the age of the data, whether the data is 
true data (received from the MIS) for the system or 
system initialization data, etc. At step 45, this weighted 60 
data is then averaged to generate a weighted average 
call volume. At step 47, the method continues by pro- 
jecting the weighted average call volume into corre- 
sponding increments throughout the future time span. 
In other words, if the previous steps have calculated the 65 
weighted average call volume for Tuesdays at 9:00 a.m. 
to be 362, this figure is projected into each Tues- 
day/9.00 slot of the future time span. 



10 

The last step in the loop in the generation at step 49 of 
a calendar factor (for the increment) from the forecast 
base period historical data. The calendar factor repre- 
sents a relative weighting of call volumes by week of 
month. Each month is by convention separated into 
first, second, next to last and last weeks. By way of a 
simple example, assume the historical data shows that 
1 10 calls were received during the particular half-hour 
on Monday of week 1 of the month in question, that 100 
calls were received during the corresponding half-hour 
on Monday of week 2, that 90 calls were received dur- 
ing the half-hour on Monday of the next to last week, 
and that 100 calls were received during the half-hour on 
Monday of the last week. Given 400 total calls or an 
average of 100 for the particular half-hour/Monday, a 
calendar factor for the particular half-hour for Monday 
of week 1 would then be calculated as 110 (the actual 
number of calls) divided by 100 (the average number of 
calls) or 1.1; the calendar factor for the particular half- 
hour for Monday of week 2 would be 100/100 or 1.0, 
and so forth. If a month has a weekday occurring five 
times, the calendar factor uses these four variables and 
calculates the average of the second and next to last 
weeks as the intermediate week. The calculated calen- 
dar factors are stored for the purposes to be described 
below. 

At step 51, a test is made to determine if the first day 
of the future time span is the next day (i.e. f the day after 
the forecast is being done). If not, then the future time 
span is sometime in the future and thus the growth rate 
must be extrapolated to compensate for unforecasted 
days between the previous day and the actual first day 
of the future time span. At step 53, the growth rate is 
therefore adjusted to reflect changes therein which 
would have occurred between the previous day and the 
first day. At step 55, the method continues by applying 
the growth rate, as a daily exponential rate of change, to 
the weighted average call volumes previously projected 
for the future time span. The growth rate is applied (as 
a multiplier) on a day-to-day basis from the first day of 
the future time span to a last day of the future time span. 
Thereafter, the routine enters a second processing loop 
at step 57. 

The second loop is then performed for each individ- 
ual time increment, from the first day of the future time 
span, continuing increment-by-increment, and ending 
with a last individual time increment of the last day of 
the future time period. The loop begins at step 58. As 
each new month is entered during looping, the method 
continues by generating a seasonality factor for each 
such new month. This factor is generated from the two 
(2) year historical data for each new month of the future 
time span, and it represents month-to-month percentage 
increases or decreases in call volumes. At step 59, the 
method continues by calculating a "net" seasonality 
effect, the net seasonality effect being based on the 
relative position in the month of a current time incre- 
ment. In particular, the seasonality factor is calculated 
from month-to-month variations and then applied in a 
forward and backward manner from a month midpoint. 
For example, assume the historical data evidences that 
April call volumes are 10% higher than March call 
volumes and that May volumes are 12% higher than 
April volumes. Using the 10% and 12% growth rates, 
step 57 applies implies a 10% growth rate (as a daily 
exponential rate) for each day between March 15 and 
April 15, and a 12% growth rate (as a daily exponential 
rate) for each day between April 15 and May 15. If the 
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relevant time increment is in, for example, April 10th 
(which is 5 days to April 15th and 21 days from March 
15th), then the net forward seasonality factor for the 
increment on that day will be the forward rate of 
change raised to the 5th power. The net backward sea- 5 
sonality factor will be the backward rate of change 
raised to the 21st power. This approach eliminates sharp 
discontinuities in prior art forecasts which occur across 
monthly boundaries as growth rates change. 

At step 61, the calendar factor for the increment is 10 
retrieved. Finally, at step 71, the net seasonality factor 
and the retrieved calendar factor are applied (as multi- 
pliers) to the weighted average call volume as previ- 
ously adjusted by the growth rate to complete the fore- 
cast for that increment. Once the second loop termi- 15 
nates, the method terminates. 

Although not described in detail above, data from 
so-called "special days" (e.g., Christmas, New Year's 
Day, etc.) occurring during the forecast base period is 
discarded before processing so that call volume devia- 
tions from the special days do not otherwise bias the 
forecast. Periods for which there is no data for the 
applicable half-hour period also do not affect the aver- 
age because these periods are ignored in the averaging 
calculations. 

The method of FIG. 6 advantageously eliminates the 
need for fixed factor distributions to distribute call vol- 
umes from months to weeks, from weeks to days, and 
from days to half-hour periods. The determination is 3Q 
built into the forecast method itself. This is a powerful, 
unique approach that overcomes the deficiencies of 
prior art time series forecasting. 

Although not discussed in detail, it should be appreci- 
ated that variations in the order of or aspects of the 35 
various steps shown in FIG. 6 is within the scope of the 
inventive technique. For example, to the extent the 
future time span includes any special day, the forecast 
thereof is adjusted by the stored distribution and certain 
call volume adjustment factors for that special day. 49 
Moreover, for purposes of computation, the growth 
rate factor can be applied early on the process by setting 
up an array corresponding to each half-hour period of 
each day in the future time span. The average call vol- 
ume for each half-hour (which will be calculated) is 45 
then set equal to an initial value (i.e., 1), and then the 
growth rate is applied as a daily exponential rate for- 
ward through the forecast as discussed above. 

The generate forecast routine 46 includes other novel 
features. In particular, it is known in the prior art to 50 
perform so-called "Erlang C" calculations to estimate a 
specific service level from call rates, average call han- 
dling time and the number of agents. According to the 
present invention, a method is described for using Er- 
lang C in a unique manner in that it takes the call rate, 55 
handling time and the desired service level to determine 
the necessary number of agents (i.e., the FTE). This is 
"backwards" from the way the Erlang C calculations 
are normally used. The service level is the percentage of 
calls answered within the service objective. For exam- 60 
pie, a service level goal might be that 80% of the calls 
are answered within 20 seconds. The forecasting 
method of the invention determines the number of 
agents necessary to provide a given service level speci- 
fied rather than the service level provided by a given 65 
number of agents. The method also directly calculates 
for all possible combinations of service level time and 
service level percentage whereas the prior art either 



forces a set number of fixed numbers (e.g., 70%, 80% or 
90% service levels) or extrapolates from such numbers. 

With reference now to FIG. 7, a simplified flowchart 
diagram is shown describing a method for predicting a 
number of agents required to provide a given service 
level in a force management system. The service level is 
defined by a percentage of calls answered within a pre- 
determined time. By way of brief background, the basic 
Erlang C formula set is shown below: 

p{ W> t) = C{n.a)=A/A +5, where: 

A=a n /{yi-\)\{n-a) 

B- Summation (J=0 to n— 1) d/Ji 

for 0<=a<ii. 

P{W>0}= probability of a delay in agent service 

P{W>t}= probability of a delay >t seconds 

E{w}= expected delay of service 

W = waiting time 

C(n,a)= Erlang C formula 

t= service objective in seconds 

tau= average holding time 

mu=l/tau 

lambda = average arrival rate (calls per second) 

a = offered load in Erlangs (lambda times tau) 

n= number of agents 
Note that lambda is the arrival rate in calls per second. 
Therefore, since tau is the time per call, the offered load 
or "Erlang" number "a" has no units. If the number of 
available agents is less than or equal to the Erlang num- 
ber, the number of calls waiting and the average delay 
will grow without bound. 

As described above, the Erlang C formula is used to 
calculate the probability of delay (and then the percent- 
age of calls handled within some specific number of 
seconds of delay) given the arrival rate, average call 
handling time, and the number of agents. In the present 
invention, the disclosed method is used to predict the 
number of agents required to provide a given service 
level (percentage of calls answered within some number 
of seconds). 

The method begins at step 73 by calculating the of- 
fered load "a," At step 75, the Erlang C calculation 
C(n,a) is run for n— a+1, which is the minimum of 
agents for which a meaningful Erlang C calculation can 
be made. Step 75 also calculates Erlang C for n+1, the 
next larger integer. According to the invention, the 
following approximation is exploited: the percentage 
reduction or "drop" for one more agent is nearly con- 
stant; i.e., if n + 1 yields a C(n+ l,a) 10% less than that 
for n+1, then C(n+2,a) would be a little more than 
10% less than that for n+ 1. More specifically, assume 
that for n (which is equal to a+1) 90% of calls are 
forced to wait and that when one more agent is added 
(n+1), the percentage of those calls forced to wait 
drops to 80%. Using this example, a drop value percent- 
age of (90-80)/90 or 1 1 % is then, by the approximation, 
what would be expected to happen to the percentage of 
calls forced to wait if another agent (n+2) is added. In 
other words, since 11% of 80% is 8.8%, then approxi- 
mately 71.2% of calls would be forced to wait if n+2 
agents are used to receive incoming calls. 

Turning now to the specific method, at step 77, the 
routine sets the variable PWtn=P{W>t} for C(n,a) 
and PWtnl =P{W>t} for C(n+ l,a). PWtn is the per- 
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centage of calls that wait more than "t" seconds if there to predict the value "p" which brings a result close to 
are "n" agents (and thus the service level associated the desired objective. The Erlang C loop is then contin- 
with 'V agents is (100- PWtn)); PWtnl is the percent- ually run up to calculate C(p-l,a), C(p,a) and 
age of calls that wait more than "t" seconds if there are C(p+ l,a). Typically, a winner will be found in one of 
"n+r agents. At step 79, a test is run to determine 5 these three results; if not, the routine keeps running 
whether "n" is the correct number of agents by deter- from p+ 1, p+2, etc. until it does find the winner, 
mining if (100— PWtn) is greater than or equal to the The force management system of the present inven- 
desired service level. If so, the routine returns "n" and tion also provides significant management capabilities 
the routine terminates. If (100— PWtn) is not greater as compared to prior art systems and techniques. The 
than or equal to the desired service level, at step 81 the 10 central computer 12 administrative functions (e.g., MU 
routine determines whether n-f 1 is the correct number allocations) are controlled by a team supervisor respon- 
of agents by determining if (100-PWtnl) is greater sible for long-term planning and oversight of the entire 
than or equal to the desired service level. If so, the team of agents. Management units, to the contrary, are 
routine returns n + 1 and terminates. If not, the method preferably responsible for daily schedule management 
continues at step 83 to calculate a drop percentage va- 15 and are thus controlled by an in-charge or "shift" super- 
lue = (PWtn - PWtn 1 )/P Wtn . At step 84, an estimated visor. This architecture dictates that the various respon- 
percentage waiting time M ePWt" is set equal to PWtnl. abilities of the supervisors, especially at the MU level, 
At step 85, a loop is carried out to calculate ePW- are dictated by the capabilities of that portion of the 
t=ePWt-(ePWt*drop), which determines how many system for which they are responsible. Stated diflfer- 
incrcments of the drop percentage must be made until 20 ently, the force management system is organized func- 
the value (100-ePWt) is greater than or equal to the tionally into different areas of responsibility, such as 
desired service level. At step 86, the number of itera- planning, managing, administration, etc. Therefore, 
tions of the loop plus the value (n+ 1) is then set equal efficient security controls and the like can be readily 
to a predictor value "p." implemented into the system. 

In particular, at this point the method has located a 25 As noted above, the force management system imple- 
value (100— ePWt) which is approximately the desired ments a unique user interface at the management work- 
service level. The use of the loop in step 85 is extremely station (of the central computer 12) and the MU work- 
advantageous because it obviates those expensive and stations. With reference now simultaneously to FIGS, 
time-consuming calculations of C(n,a) and PWtn (for 8-9, a schedule management screen 60 and a perfor- 
numerous intermediates values of "n" ) which other- 30 mance analysis screen 62, respectively, are shown, 
wise would have been necessary in order to reach the These screens are implemented at the MU workstation 
approximate desired result. At step 87, the conventional to enable the in-charge supervisors, by shifting back and 
Erlang C calculations are performed for C(p-l,a), forth therebetween, to make informed staffing decisions 
C(p,a) and C(p+ l,a). The routine continues at step 89 for their management units. Referring now to FIGURE 
to set PWtp-l=P{W>t} for C{p-l,a}, 35 8, the schedule management screen 60 is built around 
pWtp=P{W>t} for C(p,a) and PWtp+ 1 =P{W>t} the display of an agent list 61, a timescale 63, an array of 
for C(p+l,a). At step 91, a test is done to determine if schedule activity codes 65, and a net staffing field 67. 
(100-PWtp-l) is greater than or equal to the desired The array is subdivided into a 'time line" 64 for each 
service level. If so, the routine returns "p - 1" and the agent of the management unit, with each unit in the time 
method terminates since p-1 is the correct answer. If 40 line Preferably corresponding to predetermined period 
the test 91 at step is negative, the routine continues at of time, e.g., fifteen minute intervals. The timescale 63 
step 93 to determine if (100-PWtp) is greater than or preferably displays each "hour," with quarter hours 
equal to the desired service level. If so, the routine represented by dots: 



am PM 

.9...10..11..I2..1...2...3...4...5...6...7...8 



returns p and the method terminates. If not, at step 95 
the method tests whether (100-PWp+l) is greater 

than or equal to the desired service level. If so, the 50 The time line 64 for each agent includes one or more 

routine returns p-f 1 and terminates. If necessary (if user-defined schedule activity codes 66 therein, eg., 

PWp+1 is not greater than or equal to the desired "B" for break, for lunch, "m" for meetings, etc., for 

service level), the method continues at step 97 to per- representing the agent s status and/or the nature of any 

form another loop for m=p+2 as described until PWt activities that prevent the agent from attending to in- 

is greater than or equal to the service level for m=m+ 1 55 coming calls. 

and PWt=P{W>t} for C(m,a). As shown in FIG. 8, the time line 64 begins with the 

Therefore, according to the method of FIG. 7, two schedule start time of the first (i.e., top) agent displayed, 

initial guesses (namely, the minimum number of agents The time line 64 thus begins at the first scheduled 15 

n and n+ 1) are used as predictor values and a first loop minute time period of the first agent listed. Scrolling to 

is run up in step 85 to determine a value (100-ePWt) 60 the left or right using conventional cursor keys permits 

which is approximately the desired service level. At this the operator to view additional scheduled hours. When 

point, the method checks the estimate by calculating scrolling occurs, the start and stop times on the time line 

Erlang C for p— 1, p and p+1. Calculating the actual scroll as well. 

C(p- l,a), C(p,a) and C(p+ U) and service level exact As seen in FIG. 8, the schedule management screen 

values, one of the three is hopefully a winning value. 65 60 designates a number of function keys in a lower field 

Generally, the winning value will be the central pre- 65 of the screen. According to the invention, the system 

dieted value p for most common input data. Stated includes suitable program means, responsive to depres- 

differently, the routine uses the numbers for n and n-f 1 sion of a Sort function key, for performing one or more 
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sort functions. For example, agent names can be sorted 
in alphabetical order. Agent schedules can be sorted 
according to various start time(s) or ending time(s) 
beginning with the earliest start time or the latest ending 
time(s). Agents can be sorted by other user-defined 5 
criteria such as the members of a carpool(s), those 
agents having a lunch break at 11:30, or the like. The 
system also includes program means responsive to de- 
pression of a Find function key for enabling the opera- 
tor to locate an agent. Once located, that agent is at the 10 
top of the agent list and thus the time line may shift 
depending on whether the located agent has a start time 
different from the first agent previously displayed. As 
also seen in the figure, the screen 60 also identifies a 
Switch function key. Depression of the Switch function IS 
key toggles the display to the performance analysis 
screen 62 of FIG, 9. 

The schedule activity codes 66 are preferably color- 
coded and represent the status of the agent, namely, 
whether the agent is "Open" and thus able to handle 20 
calls or "Closed" and the reasons therefor. Status codes 
may have different letters identifying different reasons 
for unavailability such as "B" for break, "L" for lunch, 
etc. By way of example only, the following codes and 
their color representations may be used: 25 



Code 


Color 


Meaning 


Period 


White 


Scheduled open (on calls) 


"D" 


Red 


Closed, out of office 


"L" 


Green 


Closed, at lunch 


"B" 


Green 


Closed, on break 


**M" 


Yellow 


Closed, but available to open 


»C" 


Light Blue 


Closed key office functions 


»2" 


White 


Overtime Type 2 



30 



The activity codes are edited within the time line 
boundary. The time line may be extended by special 
overtime codes. Changes are made by positioning a 
cursor on the required time slot and replacing the cur- 
rent scheduled state with the desired scheduled state. 40 
The display 60 also includes the net staffing field 67 
which identifies quarter-hour staffing summary data 
depending on the cursor time line position. This data 
includes the number of required agents for the quarter- 
hour increment, the total number of agents whose cur- 45 
rent state is Open (i.e., available to handle an incoming 
call), a Net value equal to the number of Open agents 
minus the number of required agents, and a number of 
Closed Available agents, i.e., agents then presently 
working on administrative functions (recordkeeping, 50 
etc.) but that can be made available to receive calls. 
Preferably, the Net value is displayed in red when its 
value is negative and displayed in green when its value 
is positive. 

The schedule management display thus provides a 55 
unique time line (as opposed to a textual) representation 
of agents within a management unit to enable the super- 
visor to visualize occupancy and potential staffing prob- 
lems. The schedule management display cooperates 
with the related performance analysis screen 62 of FIG. 60 
9 which enables the in-charge supervisor to obtain a 
meaningful view of what call activity has actually oc- 
curred, a best guess estimate of what call activity will 
occur, and a means of making staffing decisions based 
on such information. By switching back and forth be- 65 
tween the schedule management and performance anal- 
ysis screens, the supervisor can make fast, informed 
staffing decisions. 
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With reference now to FIG. 9, the details are shown 
of the performance analysis screen 62 during a forecast 
mode of operation. As will be described in more detail 
below, the system also includes an intra-day reforecast- 
ing capability and thus the performance analysis screen 
can also operate in an intra-day mode showing real-time 
reforecasts for remaining half-hour intervals of the 
workday. The screen includes a Management Unit iden- 
tifier field 70 to identify the MU performance data being 
displayed. The performance analysis screen shows the 
MU's allocation of team data. In the forecast mode of 
operation, as shown in FIG. 9, the screen displays the 
data that was originally forecast for the particular day 
(before any intra-day reforecasting is performed). A 
date/time field 72 identifies the date and the actual time. 
A Time column 74 separates the data into preferably 
half-hour increments beginning with the shift, in this 
case 8:00 a.m. The performance data includes the fol- 
lowing data fields: Calls 76, average handling time 
(AHT) 78, Occupancy 80, Service Level 82, Staff 84 
and Over/Under 86. 

The Calls field 76 has two subfields, 'Tore'* and 
"Act." "Fore" represents the original forecast call val- 
ues for the half-hour increments and "Act" is the actual 
number of incoming calls provided from the MIS (and 
thus updated every half hour). The AHT field 78 like- 
wises includes a Fore and Act subfield to display the 
average handling time per call as originally predicted 
and as measured by the MIS. The Occupancy field 80 
includes a "Goal" subfield and an "Act" subfield to 
display predicted and measured levels of staff occu- 
pancy, respectively. Occupancy data is displayed as a 
Percentage. The Service Level field 82 includes the 
"Fore" and "Act" subfields identifying the predicted 
and measured service levels, respectively, expressed as 
the percentage of calls answered within a given amount 
of time. The Staff field 84 includes three subfields: 
"Open," "Req" and "Act." The Open subfield identifies 
the number of scheduled open staff, i.e., agents available 
to handle calls. "Req" is the number of required staff, 
and "Act" is the number of staff actually there. At any 
one time, either the Open subfield or the Act subfield 
has data the other being blank). The Open subfield is 
shown for future periods for which there is no MIS data 
yet. The Act subfield is shown for those time periods 
for which there is MIS data. Finally, the Over/Under 
field 86 represents the difference between the number of 
required "Req" staff and the number of actual "Act" or 
scheduled Open (depending on which is shown) staff. 
Positive numbers indicate an over-capacity condition, 
while negative numbers indicate under-capacity. Nega- 
tive numbers are preferably displayed in red to insure 
that the operator is immediately aware of the potential 
problem. 

The performance analysis screen includes a number 
of function keys 88. The Switch key toggles the display 
back to the Schedule Management screen of FIG. 8. 
Depression of the Intra Key enables the operator to 
change the mode of operation to an "intra-day refore- 
casting mode." Intra-day forecasting continually looks 
at the performance of the system and the original fore- 
cast data up to the time of the day for which data has 
been received. Using a reality weighting factor, which 
takes into consideration the amount of data received 
(i.e., how early in the day the intra-day reforecast is 
being computed), the system reforecasts the conditions 
expected for the rest of the day. The intra-day mode is 
entered upon depressing the Intra key of the terminal. 
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The Intra-day forecast is accomplished by applying a 
ratio of actual to forecast data to each of the remaining 
cells (i.e., half-hour increments) that have no real data, 
moderated by a reality ratio as will be described below 
in more detail with respect to FIG. 10. 5 

According to another feature of the invention, local 
staffing changes at the MU level (which as described 
above are implemented by the in-charge supervisor) are 
transmitted back to the central computer databases and 
are rebroadcast back (preferably in real-time as data is 10 
received) to all affected management units in the sys- 
tem. Therefore, all of the MU supervisors can continu- 
ously view the team statistics even as local staffing 
changes are dynamically implemented at other manage- 
ment units. Referring briefly to FIG. 9, the AHT, Occu- 15 
pancy and Service Level fields reflect team data while 
the Calls, Staff and 0/U fields reflect MU data, after 
allocation based on the appropriate MU percentage. 

The system also provides a "what-if 1 capability to 
allow the call center supervisor or in-charge supervisor, 20 
as the case may be, to play "what-if * games with the 
number of scheduled open agents for a particular time 
period. Thus, the call center or "team" supervisor can 
monitor the forecasted call activity for the entire team 
and can see the effects on team service level of altering 25 
the number of open agents for the rest of the shift. For 
example, if the MU supervisor desires to determine the 
effects of some unexpected agent absences, an Nbr 
Open key of the terminal is depressed. When the key is 
struck, a detail window appears on the screen: "Number 30 
Open of _for HH:MM produces Service Level of 
XX%" The entry field will default to the value (num- 
ber) of Open key agents displayed on the current Sched- 
ule Management screen. The HH:MM reflects the time 
row that the cursor was positioned on when the func- 35 
tion key was depressed, When the a new value of the 
number of open agents is entered, the system calculates 
the expected service level for the period. The cursor 
stays on the entry field so that different values may be 
tried. Once the effects of the absences are determined, 40 
the in-charge supervisor can toggle back to the schedule 
management screen and modify agent schedules ac- 
cordingly if necessary. 

Referring now to FIG. 10, data flow within an MU 
workstation is shown in detail. The workstation datas- 45 
tores are those required by the system to support local 
(i.e., MU) needs of the in-charge supervisor for a partic- 
ular MU. Thus, the data brought down and stored at the 
workstation is only that necessary and sufficient for MU 
management. As seen in FIG. 10, the workstation in- 50 
eludes an Individual Schedules dataset 102 which con- 
tains the schedules of a particular day for the agents of 
a particular MU. A Results dataset 104 contains the 
actual call volume and agent performance statistics 
recorded for the entire team at half-hourly intervals. It 55 
is a replica of the set stored on the central computer, but 
generally only the actual data for the current shift is 
stored locally. A Detailed Forecast dataset 106 contains 
the predicted half-hourly call volume and AHT. Car- 
ried with this dataset are the MU allocation numbers for 60 
the corresponding halfhour periods. An MU Alloca- 
tions dataset 108 provides the definitions of the MU 
allocation numbers. The definitions give the percentage 
of the incoming calls directed to particular MU's. 

The workstation includes two build functions: a build 65 
performance analysis screen function 110 and a build 
schedule management screen function 112. As de- 
scribed earlier, the in-charge supervisor can toggle or 



"hot-key" back and forth between these two functions. 
The build performance screen function 110 operates as 
follows. Assume that at the start of the shift there is no 
past data for that shift, i.e. there is no data in the work- 
station Results dataset 104. Thus, the data to be written 
to the screen is forecast data from the workstation De- 
tail Forecast dataset 106. Referring briefly back to FIG. 
9, the first column to be written is the forecast Calls 76 
allocated to that particular MU. The build function 110 
derives the MU call volumes from combining the team 
call volume predicted for the shift in the Results dataset 
104 and the MU allocation from the MU Allocation 
dataset 108. As described previously, the screen items 
AHT, Occupancy and Service Level are all team pa- 
rameters and are taken from the Detailed Forecast data- 
set 106 directly. 

The Staff column 84 of FIG. 9 is the staffing for the 
MU. The required MU values (Req) are calculated from 
the required team values and the MU allocations for the 
shift. The number of Open agents for the shift is calcu- 
lated by subprocess 114 from the workstation's Individ- 
ual Schedule dataset. After the end of every half hour 
period, actual performance data is received from the 
central computer 12. The team values for that half-hour, 
namely, AHT, Occupancy and Service Level, are writ- 
ten directly from the data. The MU Call Volume is 
calculated from the MU allocation of the actual team 
call volume. MU Required staffing remains unchanged 
and the actual MU staffing is obtained from the central 
computer by way of the MIS. 

As described above with respect to the intra-day 
refo recasting capability, every halfhour throughout the 
shift, the call volumes for the rest of the shift are recal- 
culated based on the actual call volume data received 
earlier in the shift. The recalculation is performed by 
subprocess 116. Again, the calls are forecasted for the 
MU on an allocated basis. The number of MU agents 
required for the reforecast MU call volumes is calcu- 
lated using an Erlang C method. These reforecasted 
values do not have to be stored or sent back to the main 
computer data base. 

An example of the intra-day reforecasting provided 
by subprocess 116 can now be described. According to 
the technique, a reforecast ratio (Rf) is first generated 
equal to the summation of Actual data divided by the 
summation of Forecast data for periods having actual 
data. A so-called reality ratio is then generated and is 
defined as equal to N/(N+1)] 2 , where N is the number 
of periods of actual data. The following is an example of 
this calculation: 



Fore 


Act 


100 


120 


150 


180 


200 





The reforecast ratio (Rf)=(120+ 180)/(100+150)= 1.2. 
The reality ratio (Rl)=[i] 2 =0,445, since N=2. The 
reforecast value for a subsequent period p, having an 
initial value (V p ), is then found from the equation: 
V=V[(l+(Rf-l))*Rl). In this case, the reforecast 
value for the third period is then: 

V 3 =200* (1+(1.2-1))»0.445J«217.8 

When actual MIS data is received, the reforecast pro- 
cess is automatically redone. This reforecasting is done 
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against the original data, not against the reforecast base. The tour/schedule generation method is shown in 

That is, if a reforecast has increased a call volume by FIG. 11. The main routine begins at step 130. For each 

25%, the automatic reforecast works against the base agent who may be used, this step calculates the days and 

not the reforecast number. time intervals and days the agent may possibly work. 

Referring back to FIG. 10, the final subprocess for 5 This set of days and time intervals is then called the 

the Performance Analysis Screen is the subprocess 118 "coverage" contributed by that agent. At step 132, all 

which provides the "what-if ' capability of recalculat- t he agent coverages are added together to get total 

ing the Service Level for changes in the number of coverage for each interval of each day. 
Open agents. The latter capability is purely a passive met hod evaluates candidate tours based on a sum 

"what-if function and the results are not stored. 10 of ^ values signed to each interval the tour covers. 

Turning now to the build schedule management Usmg the staffing requirements and the tour evaluation 

screen function 112, the timelines for the agents are heuristics, the method continues at step 134 to create a 

provided from data received from the Individual two-dimensional evaluation array (one dimension is the 

Schedules dataset 102. The build function 112 generates d of the week and the other is ^ ch 15 interval 

the Schedule Management screen of FIG 8. Active Qf ^ > ft ^ sum of the values for 

management changes are made : by the in-charge su- ^ of ^ d fi ^ ^ h fa 

pervisor by the process 120. Such changes are then ^ lookin nl 

immediately sent to the Individual Schedule data* .102 J ^ wQrked ^ usi 

and a corresponding dataset (not shown) located at the _ . 4 «- * j 4 « , , ,i^Ja 

A . r A f , v . ' _ 20 the staffing requirements and the previously calculated 

central computer. A send requirements subprocess 122 * H ^ . , \, , / . _ 

transfers requirements information from the build per- availabIe ^ vera * e ' r determines he 

formance analysis screen function 110 to the build Pnonty order of for tour generation. In this step 

schedule management screen function 112. A central * e davs are sorted bv the ratl ° of requirements to avail- 

computer data handler function 124 handles the data able coverage. 

traffic between the main computer and the workstation. 25 are sti » davs Wlth requirements that can 

The list of MU agents and their schedules are ob- be satisfied, the method continues at step 138 to deter- 
tained from the workstation Individual Schedules data- mine which day is the highest priority day among those 
set 102. The net staffing field 67 represents the staffing for which tours can still be generated. Using the agent 
requirements for the current quarter hour as determined 3Q selection criteria and template evaluations, the method 
by the position of the cursor relative to the schedule continues at step 140 to choose the agent for whom a 
timescale 63. The first three variables of the net staffing tour should be generated. At step 142, a selection is 
field are obtained from the corresponding performance made from among the templates available for the agent, 
analysis screen and are adjusted to reflect quarter-hour In particular, the method selects the template and the 
requirements. The Closed Available value is obtained 35 variation of that template that has the highest "merit" 
from the Individual Schedules dataset 102. according to the evaluation array, subject to general 

The force management system of the present inven- and agent-specific constraints. At step 144, the available 
tion also includes the capability to efficiently generate coverage and the priority order of days is recalculated, 
optima] workshifts ("tours") for agents and to generate if a t this point extra tours must be generated because 
schedules to satisfy agent preferences, availability and ^ 0 f agent constraints (e.g. minimum days per week of 
seniority. The tour/schedule generation method uses wor k), the routine continues at step 146 and generates 
the following conventions: such t0 urs as follows. While there are agents for whom 

1) "requirements" to mean a forecasted need for staff- more tours must be generated, the routine begins at step 
ing, in quarter-hour intervals for some time period 148 by selecting the next agent (in no particular order), 
(e.g., a week), . 45 At step 150, the highest Priority day for which that 

2) constraints to mean the tour templates and their t ^ work ^ does not ^ a tour is ^ 
rules governing work schedules (e.g. amount of geIected ^ ^ tour vafiation is ^ genera ted at 
time worked number of breaks, days and times of step 152 flS described above . ^ sub j oop term inates 

„ agen i avai a „ * ty '' , . r> upon recalculating the available coverage and the prior- 

3) preferences to mean per-agent desires for partic- 50 . f d ? 144 

ular kinds of work schedules within the limits im- lty ° raer . CZy * m ™* ? „ * . ct _ tc , . . . a 
posed by the constraints, and ^l^VTT ^ f P a b \ mi ^ g ? 

4) "selection policy" to mean precedence rules for P** throu * h dl the gyrated tours, readjusting break 
deciding which agents work when staff supply times to improve smoothness of the requ^ements cover- 
exceeds the need 55 age ' At step 15 ' a paSS 1S e through the generated 

The preferences desirably supported (in priority order) tours lookm £ for that 680 be elated without 

are: number of days worked, which days are worked violating staff requirements or agent constraints. There- 

and which are off, number of days for particular tem- a * ste P 16 °- a 860011(1 P 8 * B made » re-adjusting 

plates, which days are worked for particular templates, break times. 

tour start times and lunch times. The task of schedule 60 At ste P 162 > the routine then begins a pass through 
generation is to find a set of schedules, taking all the the generated tours for each type of preference sup- 
above factors into account, that are good or optimal ported. In each case, the method tries to trade tours or 
according to some evaluation criteria. Examples of such breaks among agents to improve the match between 
criteria might be minimizing total overstaffing without assigned tours and agent preferences, without violating 
allowing any understaffing, doling out available work 65 any hard constraints or higher-priority preferences, 
time fairly among part-time personnel, minimizing labor The following is a pseudocode listing of several of the 
cost while meeting at least 95% of projected staffing subroutines of the main routine described above in FIG. 
requirements, or many others. 11: 
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CALCULATING AN AGENTS COVERAGE 

For each tour template the agent may use on a given 
day: 

Mark as covered all intervals from the earliest al- 5 
lowed start to the sum of (latest start time plus tour 
length plus maximum split length. 

If the template has a required split and all combina- 
tions of tour start and split length would leave 
some intervals within the split, unmark those inter- 10 
vals. 

If the allowed slack in tour start time and break start 
times are such that some intervals will be within a 
break under any template variation, unmark those 
intervals. 15 

Logically OR the marked intervals with those 
marked from other templates. 
Marked intervals constitute the agent's coverage. 



CHOOSING AN AGENT FOR TOUR 
GENERATION 
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For every agent in the pool from which the routine is 
working: 

If the agent already has a tour for this day or the 
agent is not available to work this day, do not 
choose this one. 

If this agent must be used and if this day is necessary 
to make the agent's minimum allowed work days, 
choose this agent immediately. 3Q 

If the current provisional choice does not have 
his/her minimum days requirement satisfied and 
the agent being examined does, do not choose this 
one. 

If the routine has gotten this far, calculate the figure 35 
of merit for each of the agent's available tour tem- 
plates. If no templates work for this day, don't 
choose this agent. Otherwise, note the merit figure 
for the best of the templates. 
If there is no current provisional choice, if the provi- 
sional choice has his minimum days already and 
this agent does not, or if this agent's template merit 
is better than that of the current provisional choice, 
make this agent the provisional choice. 
If this agent's merit figure is less than that of the 45 
provisional choice, don't choose this agent. 
At this point, both a current provisional choice and this 
agent qualify to be chosen, and both have equal tem- 
plate merit figures. Determine the new provisions 
choice based on the following comparisons: 50 
If both agents prefer to have this day off, make the 

less senior agent the provisional choice. 
If only one of the agents prefers to have this day off, 

make the other one the provisional choice. 
If neither agent wants this day off, make the more 55 
senior one the provisional choice unless getting this 
tour would cause that agent to exceed his preferred 
number of days worked. 



SELECTING THE TEMPLATE FOR TOUR 
GENERATION 
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If the agent has only one template or only one that is 
valid for the day being handled, choose that one. 

Determine the M slack" associated with each template. 
That is, the number of days for which other templates 65 
may be chosen without violating the minimum-use con- 
straints for this template. 

For every template available to the agent on this day: 



If agent availability conflicts with the use of this 
template, do not choose it. 

If "slack" considerations force the selection of a tem- 
plate other than this one, do not choose this one. 

If choosing this template on this day would cause a 
conflict between the template's maximum-use con- 
straint and its forced-days constraints, do not 
choose this template. 

If the routine has not disqualified the template, calcu- 
late the merit of the template's best variation. 

If this template's merit is the best so far, make it the 
provisional choice. 

What is claimed is: 

1. A method for managing personnel in a telephone 
call center in which there is a varying workload by time 
of day and by day of week to be staffed with a variable 
number of agents, comprising the steps of: 

(a) generating call handling performance data for the 
telephone call center, the call handling perfor- 
mance data including average call arrival rate and 
average handling time per call; 

(b) generating a forecast of a call load expected to 
occur at the telephone call center during a prede- 
termined period in the future; 

(c) defining a desired service level for the telephone 
call center during the predetermined period, the 
desired service level equal to a percentage of calls 
answered within a predetermined time "t"; 

(d) predicting a number of agents required to provide 
the desired service level during the predetermined 
period by: 

(1) calculating an offered load "a" equal to the 
average arrival rate of calls for the call center 
times the average handling time per call; 

(2) calculating PWtn using an Erlang C function 
C(n,a), for n=a+ 1, where PWtn is a percentage 
of calls that wait more than "t" seconds if there 
are "n" agents; 

(3) if (100-PWtn) is not greater than or equal to 
the desired service level, repeating step (2) for 
PWtnl, where PWtnl is a percentage of calls 
that wait more than "t" seconds if there are 
"n+1" agents; 

(4) if (100-PWtn) is greater than or equal to the 
desired service level, define n as the predicted 
number of agents; 

(5) if (100-PWtnl) is not greater than or equal to 
the desired level for n=n+l, calculate a drop 
percentage (PWtn- PWtn l)/PWtn; 

(6) set an estimated percentage waiting time ePWt 
equal to PWtnl; 

(7) calculate ePWt=ePWt-(ePWt*drop percent- 
age) to determine how many increments of the 
drop percentage must be made until 
(100— ePWt) is greater than or equal to the de- 
sired service level; 

(8) set a predictor value p equal to the determined 
number of increments plus (n+1); 

(9) calculating Erlang C(n,a) for n=p— 1, p and 
P+l; 

(10) repeating steps (3)-(4) for successive values of 
n=p-f 1, p and p+ 1 until a value of n is located 
such that (100— PWtn) is greater than or equal to 
the desired service level; and 

(e) allocating personnel in the telephone call center 
according to the predicted number of agents. 

2. A method for managing personnel in a work center 
in which there is a varying workload by time of day and 



06/28/2003, EAST Version: 1.03.0002 



by day of week to be staffed with a variable number of 
workers, comprising the steps of: 

(a) generating work request performance data for the 
work center, the work request performance data 
including average work request arrival rate and 
average handling time per work request; 

(b) generating a forecast of a work request load ex- 
pected to occur at the work request center during 
a predetermined period in the future; 

(c) defining a desired service level for the work cen- 
ter during the predetermined period, the desired 
service level equal to a percentage of work re- 
quests answered within a predetermined time "t"; 

(d) predicting a number of agents required to provide 
the desired service level during the predetermined 
period by: 

(1) calculating an offered load "a" equal to the 
average arrival rate of work requests for the 
work center times the average handling time per 
work request; 

(2) calculating PWtn using an Erlang C function 
C(n,a), for n=a + 1, where PWtn is a percentage 
of work requests that wait more than "t" seconds 
if there are "n" workers; 

(3) if (100-PWtn) is not greater than or equal to 
the desired service level, repeating step (2) for 
PWtnl, where PWtnl is a percentage of work 
requests that wait more than "t" seconds if there 
are "n+1" workers; 

(4) if (100-PWtn) is greater than or equal to the 
desired service level, define n as the predicted 
number of workers; 
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(5) if (100-PWtnI) is not greater than or equal to 
the desired level for n=n+l, calculate a drop 
percentage (PWtn- PWtn l)/PWtn; 

(6) set an estimated percentage waiting time ePWt 
5 equal to PWtnl; 

(7) calculate ePWt=ePWt-(ePWt*drop percent- 
age) to determine how many increments of the 
drop percentage must be made until 
(100— ePWt) is greater than or equal to the de- 

10 sired service level; 

(8) set a predictor value p equal to the determined 
number of increments plus (n + 1); 

(9) calculating Erlang C(n,a) for n=p— 1, p and 

P+l; 

15 (10) repeating steps (3H 4 ) f° r successive values of 
n=p+ 1, p and p+ 1 until a value of n is located 
such that (100— PWtn) is greater than or equal to 
the desired service level; and 
(e) allocating personnel in the work center according 
20 to the predicted number of workers. 

3. A method for managing personnel in a telephone 
call center in which there is a varying workload by time 
of day and by day of week to be staffed with a variable 
number of agents, comprising the steps of: 
25 (a) generating a forecast of a call load expected to 
occur at the telephone call center during a prede- 
termined period in the future; 

(b) defining a desired service level for the telephone 
call center during the predetermined period, the 

30 desired service level equal to a percentage of calls 
answered within a predetermined time; 

(c) predicting a number of agents required to provide 
the desired service level during the predetermined 
period by a direct calculation; and 

35 (d) allocating personnel in the telephone call center 
according to the predicted number of agents. 
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